COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Denny,
C00013 ENDMK
C⊗;
Denny,

We believe that the future Tut-I's can be much improved by
the following actions and policies.  Priorities range from
1 (we won't do TUT-I without this) to 10 (a mild suggestion):

Perhaps the chief focus for the next TUT-I should be on the
Lab (MINIMA) for symbolic differentiation and integration.
Priority 1 item: The script handed out to the students is
indeed something they can get the program to do.  This has
two important criteria: there must be no bugs (unimplemented
features, rules that cause infinite loops, etc.), and the
program must run fast enough so that they can expect to get
through the script in the allotted time.  Each of these is
important.  If the program is bad, the system crowded, etc.,
then STILL we expect the handed-out script to be pared down
BEFORE HANDING IT OUT so that it meets both criteria.
One suggestion, if we are using a high-load-average machine
still next time, is to split the first lab session into
halves, on Tue and Wed afternoon, with half the class
coming in each day, and getting the other afternoon "off",
rather than all of them getting Wed. afternoon off.

Priority 2 item: one week before the TUT-I begins, i.e., on
a Monday, we hold a meeting with all the following people
present: Denny, Steve (and/or other Minima programmer(s)),
Doug, Rick, and Lee Hecht.  At that meeting, you (Denny)
present the script, run some of the program at a couple
archetypical points in that script, report on the total
CPU time it takes to do the script, the prevailing load
averages on the machine we're to use, etc.  If the
lab is not ready, or is too slow, etc., then at that
meeting we jointly arrive at a detailed plan for having
some acceptable recourse: changing the script, changing
machines, going back to the original MacLisp MINIMA,
eliminating the lab sessions entirely, hand-simulating them, etc.

Priority 3 item: the preferred way of ameliorating the lab
problems is to improve the program.  This means:
(i) speeding it up by AT LEAST a factor of 8; that would
make it about the speed at which the program ran last TUT-I.
An additional factor of 2-4 is only slightly less necessary.
(ii) adding the various features that were spec'ed out in the
script that we (Doug) provided you with: 
	How, Why, Better-rule, Common subexpression,
	Subproblem-of, Best/Depth/Breadth-first, Tutoring,
	Caching subproblems, Organizing the rules into a hierarchy,
	Transforming subproblem-reoccurennce into a linear
	equation so that integration by parts can work usually, etc.

Our strong opinion for speeding the program up is that
it be recoded in Interlisp directly, eliminating the
MRS mid-layer.  The precise types of pattern-matching
and indexing needed for the script can be done much
more quickly than the version we had last week.
Caching intermediate (sub-)problem results will also
help, as will compiling, of course.  MRS is an interesting
research vehicle, but using it for MINIMA is like using
a MAC truck to run down a mouse: it's more than we need
and it's SO much more that it actually makes things more 
difficult to hit that mouse.

Priority 3 item: not only should the lab be speeded up, it should
be more interesting and informative to watch.  We hope that
you will do the small amount (1-3 days) of coding necessary
for it to run on the Dolphins, with separate windows
dynamically displaying
	The body of rules (highlighting the one being used)
	The body of assertional facts, known subproblems, etc.
	The tree of subproblems (highlight the current one)
If you believe this would take more than 3 days to do, I
(Doug) will be happy to spend a couple days doing it.

We would need to have a total of about 20 Dolphin-hours set aside for
TUT-I that week, which should not be very painful as we can
schedule those hours months in advance.

Priority 4:  Given the "time off" periods (Tue and Wed afternoons,
Tue for half the class and Wed for the other half), we propose to
use them to provide an optional technical TEK pitch: the sort of
talks that Lee and Rick delivered on Friday: what exactly does
our company sell and do, who comprises it, what kinds of relationships
do we want to set up, etc.  Some students strongly want this, and
some strongly don't, so using the otherwise-time-off period for it
seems about right.

This about ends our comments on the Lab. Our next item is something
we have asked about since before the first TUT-I was given; it has
slowly risen in seriousness to its present Priority level of 2:
Priority 2: Reduce the variance in the background and intended goals
of the audience.  Some of these people are extremely well prepared
in AI, Lisp, expert systems, etc.; at the other extreme, many of
them come from classical DP backgrounds, with little motivation, 
litle willingness to open their minds and challenge their paradigms.
Some of the students will be expected to become KEs; some are managers;
some are scouts for their managers and must gather ammunition with
which to pitch a case to enter ESs and/or buy Lisp machines.
Their focus is: what's avaliable, what does it cost, who can use it,
how much manpower does it take, what are proven cases of cost-effectiveness,
etc.  To meet this problem, we propose that various flavors of TUT-I
be advertised and marketed, with specific audiences in mind:
	The manager or management scout
	The uninformed programmer
	The already-budding KE
Note that this is largely a marketing solution.  We will change our
offering to suit the various groups, but simply the act of separating
them is the most important action item.

Priority 2:  Given the strong interest in management and business
details even in the previous TUT-I, and anticipating a stronger
focus onthat in the Management-oriented future TUT-I's, we need
to get some hard data to present to them.  Lee, Rick, Jerry, and
others can help with this.  We need
	Case studies, with as much detail -- including dollar amounts
		and times -- as possible.
	Marketing studies
	Executive briefing materials (staffing a KE project, machines,...)
	Detailed specs on various Lisp machines, and on large
		machines which run various forms of Lisp.
	Samples of various Lisp environments.  This (and previous item)
		can probably be obtained from Fahlman and Steele at AAAI.
		They are giving a tutorial on Lisp environments just
		prior to AAAI; we should send someone to take it all down.
	Samples of running various extant ESs.  These samples can be
		hardcopy traces, living running programs, vidoetapes, etc.